Hey 👋

im thinking to remove the collectionId from the metadata. This could be used to scam people, if dApps not validate, if the collectionId is valid. So for example the NFT creator can add an collectionId from another NFT collection and copy it. This feature is already solved by the "issuerId" which can not be changed or add manually. Also, we need less data so we need less tokens for storage deposit.

What do you think?

Hey 👋

im thinking to remove the collectionId from the metadata. This could be used to scam people, if dApps not validate, if the collectionId is valid. So for example the NFT creator can add an collectionId from another NFT collection and copy it. This feature is already solved by the "issuerId" which can not be changed or add manually. Also, we need less data so we need less tokens for storage deposit.

What do you think?

As collectionId is optional I think it is ok to keep it. It can be useful sometimes for easier access to the ID but you can always also just ignore it 🤔

I was thinking about adding something 😅 .
What about having an additional data property. And than you either have to provide an uri or data property.
Because otherwise how would you use this standard if you want to store your data on-chain in the output? 🤔

I was thinking about adding something 😅 .
What about having an additional data property. And than you either have to provide an uri or data property.
Because otherwise how would you use this standard if you want to store your data on-chain in the output? 🤔

I wouldn’t complicate. You can always store it within uri. Same way as you would set src attribute in html

for example
<img src="data:image/png;base64,iVBORw0KGgoAAA ANSUhEUgAAAAUAAAAFCAYAAACNbyblAAAAHElEQVQI12P4 //8/w38GIAXDIBKE0DHxgljNBAAO9TXL0Y4OHwAAAABJRU 5ErkJggg==" alt="Red dot" />

I was thinking about adding something 😅 .
What about having an additional data property. And than you either have to provide an uri or data property.
Because otherwise how would you use this standard if you want to store your data on-chain in the output? 🤔

I wouldn’t complicate. You can always store it within uri. Same way as you would set src attribute in html

for example <img src="data:image/png;base64,iVBORw0KGgoAAA ANSUhEUgAAAAUAAAAFCAYAAACNbyblAAAAHElEQVQI12P4 //8/w38GIAXDIBKE0DHxgljNBAAO9TXL0Y4OHwAAAABJRU 5ErkJggg==" alt="Red dot" />

My bad. I totally forgot the data URI scheme 😅

As collectionId is optional I think it is ok to keep it. It can be useful sometimes for easier access to the ID but you can always also just ignore it 🤔

Yes, the collectionIdis optional in the metadata but required as ìssuerID` on a collection. So its optional to store the data twice :P

And i can add everything i like to the collectionId field - also collectionIds from other existing collections which i could use to scam people on dApps like marketplaces where this collectionId not gets validated.

So why using an extra attribute which information is already present and add an potentially scam potential? Or am I misunderstanding something?

I agree that it does not make sense to include the collectionId. Besides opening the door for scammers, if it is accidentally messed up by the creator of an NFT collection and not noticed in time, there might be invalid NFT collections out there.
So why even make it complicated and give minters another possibility to make an error when we can just check the NFTid of the collection NFT?
No dapps will/should implement relying on the collectionId for verification if it is well known that it can be set as any arbitrary value.

Yeah makes sense thinking about it 👍

Hi team. I'd like to suggest to add an additional (optional) key in the NFT schema.

We are used to thinking of NFTs in relation to digital artworks and in general use cases where a single token can represent an object of value after it has been created and published by the author.

However, there are many use cases where a non-fungible token can represent a physical object that belongs to a collection of objects, i.e., a production batch, and which is very interesting to be able to follow the history of the production process from the beginning of the process.

From pharmaceutical to fashion to automotive, the number of real-world cases where this scenario applies is endless.

Sometimes the life of the post-production object is normally of little interest, especially if they are consumable products, but it is almost always interesting to trace the production process of these products. Addresses can be used to represent the stages into which the production process of each object is divided. Thus transactions that spsot the NFT from one address to another represent optimally the production process.

The optional key I suggest adding contains an array of addresses that where NFT can be sent. If this key is present, the transaction that moves an NFT from one address to another must be valid for the array. An "any" operator allows the NFT to be freed from the last address.

For example:
allowed_address_sequence: add1, add2, add3, any

A tx that moves the NFT from add1 to add2 is valid.
A tx that moves the NFT from add1 to add3 is invalid
A tx that moves the NFT from add1 to addx is invalid
A tx that moves the NFT from add2 to add3 is valid
A tx that moves the NFT from add3 to addx is valid

An additional use case for the suggested key is a public voting process where one person can vote once.

In these voting scenarios a voting authority is normaly requred present and required to identify the voters and authorize them to partecipate to the pool process. The vote, in most of the cases need to be secret, but this point is out of topic here.

A simple solution to provide an authorization to the voters is to mint and sent to them an NFT that have to send to a final destination address with the vote included in the tx metadata.

So in this case the allowed_address_sequence can be a list of two address: voter's address where the NFT is minted, pool address where the NFT have to be sent.

Hey Stefano, thanks for your input! This sounds like an ideal use case for Smart Contracts. I see the problem, that all dApps needs to check if the address is valid or not. That means, the protocol could just send the NFT to an address which is not allowed. There is no "if/else" here on protocol level, this needs a smart contract. Because of this reason, i would say this should not be part of the NFT standard. You could extend the standard for your applications. If i miss something, please let me know. Is there anything like that on other NFT standards?

I understand your point. In fact, my first thought was to use a SC for these kinds of scenarios, but objectively for some of these cases it might be too much of a heavy duty.

Instead of modifying the NFT standard, it might make more sense to propose a new Unlock condition so that we can limit the displacement of a genenric token on specific addresses?

On second thought, both Unlock condition and Smartcontract are not safe solutions.

In fact, Unlock conditions, if I have not misunderstood, are related to the individual tx, not to the object being moved. This implies that the next "owner" can freely define his own Unlock condition that replaces the previous one.

More or less the same applies to Smartcontract, which being deplyoed by an owner, can always be replaced.

In my initial idea these validity conditions are to be included in the immutable part of the NFT.

Obviously it would be useful for the network to take them into account by considering invalid a tx that moves an NFT to an address not authorized by its author because if the NFT is moved, then there is no way to avoid the new owner to use as he prefers.

I've spoke with @Phyloiota the other day as he asked me to review Shimmer OG NFT collection. I've provided him with feedback and he asked me to share it here so here it goes:

1. Alias should have been used to issue NFT collection. We do this because it was suggested by various people from IF after we did many reviews/testing with various parties. It's great suggestion. Alias can be used for various things (i.e. Alias can be transferred to new owner or even to a party that wants temporary do something with the collection). TIP27 does not specify how collections / NFT should be minted and I think it should be more specific!
2. Collection NFT metadata have "type": "text/html" and "uri": "https://shimmer.network". This is more an additional attribute. Uri should be reserved for preview image so it can show collection banner. Right now, this NFT collection will have no image once it's imported into various NFT marketplaces.
3. I noticed Shimmer OG NFT has no props/stats. This significantly decrease value of the NFT and it's rarity. Owner will not know anything about the NFT. NFT should always have some stats/props and it should be encouraged.
4. NFT uri could have just been ipfs://QmPoYcVm9fx47YXNTkhpMEYSxCD3Bqh7PJYr7eo5YjLgiT to save on storage deposit.

I'm not sure if above is something we want to enforce within the specification but it might be worth to consider some of them. Some of them can also be great "suggestions" for artists to follow.

Hey Adam, thanks for you feedback!

TIP27 does not specify how collections / NFT should be minted and I think it should be more specific!

It's defined here - but it should be more specific and the Alias part is missing - https://github.com/Kami-Labs/tips/blob/main/tips/TIP-0027/tip-0027.md#minting-l1-nft-collections

Collection NFT metadata have "type": "text/html" and "uri": "https://shimmer.network". This is more an additional attribute. Uri should be reserved for preview image so it can show collection banner. Right now, this NFT collection will have no image once it's imported into various NFT marketplaces.

Very Good point - so the example is a bit miss leading and we could need something like homepage

"uri": "https://my-awesome-nft-project.com",

I've spoke with @Phyloiota the other day as he asked me to review Shimmer OG NFT collection. I've provided him with feedback and he asked me to share it here so here it goes:

1. Alias should have been used to issue NFT collection. We do this because it was suggested by various people from IF after we did many reviews/testing with various parties. It's great suggestion. Alias can be used for various things (i.e. Alias can be transferred to new owner or even to a party that wants temporary do something with the collection). TIP27 does not specify how collections / NFT should be minted and I think it should be more specific!
2. Collection NFT metadata have "type": "text/html" and "uri": "https://shimmer.network". This is more an additional attribute. Uri should be reserved for preview image so it can show collection banner. Right now, this NFT collection will have no image once it's imported into various NFT marketplaces.
3. I noticed Shimmer OG NFT has no props/stats. This significantly decrease value of the NFT and it's rarity. Owner will not know anything about the NFT. NFT should always have some stats/props and it should be encouraged.
4. NFT uri could have just been ipfs://QmPoYcVm9fx47YXNTkhpMEYSxCD3Bqh7PJYr7eo5YjLgiT to save on storage deposit.

I'm not sure if above is something we want to enforce within the specification but it might be worth to consider some of them. Some of them can also be great "suggestions" for artists to follow.

1. Not sure if it has any benefits in this use case. Even an NFT can be transferred. The powerful part of Alias is the unlock conditions with state and governance controller I would say.
   And I think if there is a valid case to use that, it should probably be a separate TIP. This one being the easiest Implementation. In the end the NFT has some features of the Alias. So why not use it for some use-cases?
   But I have no strong opinion against using an Alias. (Maybe the only one being that maybe collection NFTs are a well known thing, alias NFTs not )
   What do you mean with TIP27 doesn't specific how it should be minted? What needs to be more specific in your eyes?

2. NFTs can not just be images. So you could also specify in your guide that if someone wants to host on soonaverse he should add a image to the collection uri as a preview 🤔
   In the end the TIP doesn't restrict you in what to put into uri.
   I don't think we should add a homepage property tho tbh. You could add such additional properties to attribute to I guess 🤔

3. The TIP defines optional attributes. I even suggested to use them to define for example why you got the NFT (Won in Giveaway, participated in Singapur...). They didn't do it. And that's fine. we shouldn't force users to use those. But again, any marketplace could give such infos as tips in their guides. Want to increase value for your NFT? Add attributes.
   After all again, not all NFTs are "just" images you try to sell.

4. This is a valid point which was actually also raised internally by @nicole-obrien afaik.

Thanks for your feedback ❤️ . I personally think most of this things should be optional.

Thank you to everyone who worked on TIP-27! 💯